前言

這個是屬於近期發生的事情，(當然如果讀者已經過了 2026 年，那應該就撐不上近期發生的事情了)
自從 bun 加入了 Anthropic 就有 AI 賦能，網上關於 bun 重寫的狀態，詳情可以看 bun 的官方聲明

🚪可以參考傳送門🚪

簡單地說(懶人包) : 原本的 Zig 程式碼是單一編譯單元，
Jarred 想把新的 Rust 程式碼拆成約 100 個 crate 以加快編譯速度，
同時要避免循環依賴並盡量減少與原始 Zig 實作的差異

爭議思考

關於 bun 把 zig 轉成 rust 的這個過程，利用 AI 之力去實現，不免有一些人提出質疑
像是 審核問題
以及相關討論

如今的 bun

如今的 bun 已經有非常多 feature 會選用 rust 作為接下來的改動，固然有很多值得考慮的點

1. **記憶體安全 **

Jarred 表明不想花大量心力處理各種 memory leak 相關的問題以及穩定性問題，相較於 zig
rust 確實兼具效能，以及更穩定的選擇

2. zig 刻意不提供編譯期記憶體安全的保證

有寫過 zig 的朋友肯定知道， zig 有他的固有哲學，雖然一樣是沒有 GC,但 Rust 好歹有 borrow checker
在編譯階段基本上等同於保姆級的對待，某些層面來說，對於 bun 走到今日的狀態來說，反倒 zig 會成為阻礙
其實可以看得出來，當初 Jarred 用 zig 是對這語言來說是有愛的，但時至今日，還是必須要與現實還有穩定低頭

3. 談談 zig : GC 與手動記憶體管理混用是 Bun 特有的痛點

Bun 必須讓 Zig 的手動記憶體管理與 JavaScriptCore 的垃圾回收機制共存，
正確處理垃圾回收值與手動管理值的生命週期，一直是穩定性問題的主要來源

一個弄不好就會導致 memory leak 以及當機

4. 談談 rust : Rust 的借用檢查器能在編譯期而非執行期抓到錯誤(測試左移)

Rust 的 borrow checker會在編譯期強制執行別名與生命週期規則，寫起來較慢、學起來較難，
但 use-after-free 和資料競爭這類問題會變得很難出貨。
對於一個要處理不受信任程式碼的 JavaScript 執行環境來說，這個差異意義重大

關於網上其他人的 分析

Fuzzing 是在程式碼合併之後才進行；
CI 是在程式碼推送時才進行；執行期安全檢查與 AddressSanitizer 則是在程式執行時才進行（希望是在開發階段，而不是在 CI 才發現）
Rust 把這個檢查點提前到編譯階段

5. unsafe 關鍵字讓危險程式碼「現形」

Rust 要求用 unsafe 明確標記可能危險的操作，這讓潛在危險的操作變得可見，
進而「鼓勵重構」——意味著開發者會有動機去減少 unsafe 程式碼的使用，因為它會特別顯眼。
相較之下，Zig 裡同樣風險的程式碼是隱形的

6. Rust 生態系與貢獻者社群規模遠大於 Zig

Rust 擁有比 Zig 大得多的開發者社群
更多貢獻者意味著更快的錯誤修復、更多平台支援，以及圍繞 Bun 更健康的開源生態系，
而且 Rust 可以直接借用像 Rayon(資料平行化)和 Tokio(非同步 I/O)這類在生產環境久經考驗的函式庫

7. Rust 編譯器的錯誤訊息特別適合 AI Agent 迭代

眾所皆知Rust 的編譯非常的嚴謹，也因為這樣很適合 AI Agent 去進行重構和檢查

這七項理由正好就是 bun 改用 rust 的七宗罪

結論

簡言之，隨著團隊規模以及程式碼規模， Rust 現在很明顯是更好的選擇